Coordinating Complex Problem-Solving Among Distributed Intelligent Agents 
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ABSTRACT 

This paper describes a process-oriented control 
model for distributed problem-solving. The model 
coordinates the transfer and manipulation of in- 
formation across independent networked applica- 
tions, both intelligent and conventional. The model 
was implemented using SOCIAL, a set of object- 
oriented tools for distributed computing. Complex 
sequences of distributed tasks are specified in terms 
of high-level scripts. Scripts are executed by SO- 
CIAL objects called Manager Agents, which realize 
an intelligent coordination model that routes indi- 
vidual tasks to suitable server applications across 
the network. These tools are illustrated in a pro- 
totype distributed system for decision support of 
ground operations for NASA’s Space Shuttle fleet. 

Keywords: distributed control, intelligent coordi- 
nation, distributed artificial intelligence 

INTRODUCTION 

End-user tasks in distributed systems typically de- 
compose into sequences of interactions between in- 
dependent applications. For example, scheduling 
engines are often driven by task, resource, and con- 
straint networks derived from independent planning 
systems. Scheduling a space mission may therefore 
depend on a succession of individual data transfers 
and manipulations across several decision support 
tools and databases. Similar task decompositions 
arise in operations support for complex control net- 
works such as the Space Shuttle Launch Processing 
System (Adler, 1990). 


the absence of direct interprocess links, human in- 
tervention is required to effect transfers of data and 
control. Such involvement, whether by end-users or 
supporting network operators, impacts the produc- 
tivity and cost of frequent, high-level activities such 
as decision support. Moreover, the likelihood of hu- 
man errors may compromise quality and safety. 

Intelligent systems have the capacity to coor- 
dinate distributed problem-solving autonomously. 
However, considerable latitude exists in design- 
ing architectures for distributed intelligent control 
(Bond and Gasser, 1988). For example, interac- 
tion sequences can be automated piecemeal, by es- 
tablishing directed, data-driven control links be- 
tween individual applications. Distributing sequen- 
tial control logic in this manner is cumbersome in 
application networks that address multiple com- 
plex tasks. Moreover, directed links are difficult to 
maintain, extend, and verify when network applica- 
tions and tasks are added or modified with any fre- 
quency. Finally, highly distributed control schemes 
incur processing overhead to ensure focus and co- 
herence of autonomous problem-solving activities. 

This paper describes a process-oriented model 
for distributed coordination. The model enables 
complex sequences of distributed tasks to be spec- 
ified in terms of high-level scripts. Each script el- 
ement represents a distinct data transfer task or 
request for problem-solving skills between comple- 
mentary applications. The model also encompasses 
intelligent control modules that execute these pro- 
cess scripts automatically: individual tasks are 

routed to suitable distributed servers and results 
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are retrieved for the requesting applications. This 
model alleviates many of the difficulties faced by 
more decentralized coordination schemes. 

The new process control model was imple- 
mented as an extension to SOCIAL, a development 
tool for distributed computing across heterogeneous 
hardware and software environments. The next sec- 
tion of the paper reviews SOCIAI/s architecture 
and functionality. The following section describes 
the design and implementation of the process con- 
trol model. The model is then illustrated with 
a prototype distributed system for decision sup- 
port of Space Shuttle fleet ground operations at the 
NASA Kennedy Space Center. 

OVERVIEW OF SOCIAL 

SOCIAL consists of a layered collection of object- 
oriented tools for distributed communication, data 
management, and control (cf. Figure 1). These 
generic capabilities are bundled into active objects 
called Agents. SOCIAL provides an extensible li- 
brary of predefined Agent classes with specialized 
integration and coordination behaviors. An ap- 
plication is linked non-int rusively to an Agent via 
calls to a high-level Application Programming In- 
terface (API). Applications make API calls to in- 
voke their mediating Agent objects to execute de- 
sired distributed behaviors. Agents interact us- 
ing asynchronous message-passing. SOCIAI/s un- 
derlying layers transparently manage interprocess 
message communication across heterogeneous lan- 
guages, operating systems, and networked hard- 
ware platforms (Sy mbiotics, 1990). 



Figure 1: Architecture of SOCIAL 


SOCIAL Gateway Agents 

SOCIAL Gateway Agents provide a uniform design 
model and methodology for integrating heteroge- 
neous applications, both conventional and intelli- 
gent (Adler, 1991b). The root Gateway Agent class 
defines a full peer-to-peer control model that is in- 
herited by all specialized Gateway subclasses. This 
model invokes a set of Agent methods in a data- 
driven manner to process: (a) outgoing messages 
from the Gateway’s associated application to other 
Agents; (b) incoming messages from other Agents; 
and (c) responses to prior outgoing messages. 

An application is integrated by creating a new 
Gateway subclass, which involves specializing two 
sets of Agent methods. One set establishes custom 
mappings for application-specific data models and 
control interfaces. To simplify interactions between 
heterogeneous applications, SOCIAL transports in- 
formation in a neutral exchange format. Accord- 
ingly, each Gateway subclass must define conver- 
sion methods for translating from the application’s 
native knowledge representation model and com- 
mand interface into SOCIAI/s neutral data format, 
and vice versa. Native and neutral exchange data 
structures are accessed and manipulated using func- 
tions from the application’s programmatic interface 
and the API for SOCIAL’s data management, layer. 

The second set of Gateway methods defines the 
application’s desired interactions with other ele- 
ments of the distributed system. These control 
methods are constructed using the Gateway con- 
version methods for extracting data and knowledge, 
injecting information, or invoking application com- 
mands, as required. One method establishes server 
behaviors, which process incoming messages from 
other application Gateways and generate suitable 
responses. A second method defines client behav- 
iors. Applications configured as clients initiate out- 
going messages containing service requests via their 
Gateways. A Gateway client behavior typically in- 
jects responses to previous request messages back 
into the associated application for follow-on pro- 
cessing. A given application Gateway can sup- 
port multiple client and server interactions with any 
number of other application Agents. 
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SOCIAL Manager Agents 

SOCIAL Manager Agents provide predefined con- 
trol models for coordinating activities in com- 
plex networks of application Agents. Coordination 
among distributed problem-solvers can be achieved 
through different strategies. One approach is to dis- 
tribute control, localizing it within individual appli- 
cations. A second approach is to centralize control, 
either in a preferred application or in a dedicated, 
independent module. SOCIAL Gateway Agents 
provide flexible vehicles for implementing either of 
these opposing alternatives. Manager Agents were 
developed to support a third design strategy, which 
is to combine localized and centralized control into 
hybrid coordination architectures. 

The first SOCIAL Manager Agent defined a hi- 
erarchical, distributed control (HDC) model (Adler, 
1991a). This HDC-Manager mediates interactions 
among autonomous “subordinate” Agents much 
like a human manager. Application Gateways com- 
municate exclusively with their Manager Agent, re- 
questing information or problem-solving resources, 
and receiving responses to those requests. Subor- 
dinate Agents do not need to know about the func- 
tionality, structure, or even the existence of other 
application Agents; they only need to know (a) 
the high-level API for interacting with the HDC- 
Manager and (b) the names of the services available 
within the HDC-Manager’s scope. 

The basic operational model for the HDC- 
Manager is summarized in Figure 2. The HDC- 
Manager functions as an intelligent router of task 
requests, based on a directory knowledge base. This 
directory describes: (a) individual information re- 
sources and problem-solving capabilities; (b) the 
application Agent that supports each such service; 
(c) the message format for requesting that service; 
and (d) the server Agent’s logical address. Request 
messages from application Gateway Agents are 
posted to the HDC-Manager’s agenda queue. The 
HDC-Manager processes and dispatches requests 
asynchronously to suitable server application Gate- 
ways. These Agents, in turn, post responses from 
their applications to the HDC-Manager s bulletin- 
board” database. The HDC-Manager subsequently 


retrieves such responses and forwards them back to 
the original requesting Agents. 

f HDC-Manager Agent 1 
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I Agenda Bulletln- 



Gateway Agent 


Gateway Agent 

Application 1 


| Application! 


Figure 2: HDC-Manager Operational Model 

In essence, the HDC-Manager establishes a 
layer of control abstraction that decouples appli- 
cation Gateways from direct connections with one 
another. The centralized directory promotes main- 
tainability and extensibility over the evolutionary 
lifecycle of complex distributed systems. 

SOCIAL’S PROCESS-PLANNER AGENT 

SOCIAL’S HDC-Manager Agent supports simple 
interactions between independent distributed sys- 
tems. For example, an intelligent scheduling 
tool might query a remote shop floor production 
database to determine the availability of equipment 
or labor resources. Similarly, an intelligent opera- 
tions support application for a power management 
system might collect data to confirm a power bus 
fault hypothesis, or command an experiment man- 
agement system to minimize power consumption. 

The applications in these examples are loosely 
coupled. The scheduler uses the database solely 
as a source of current status information about its 
target domain. Similarly, operation management 
systems only interact in situations where the struc- 
tural and functional interfaces between their target 
subsystems appear to be relevant. Simple discrete 
transactions (e.g., query-response, sensor polling, 
command-acknowledgment interchanges), provide 
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sufficient coupling to enable distributed problem- 
solving activities in these contexts. The HDC- 
Manager Agent contains all of the apparatus and 
control functions required to coordinate discrete 
transactions within a distributed system. 

However, many kinds of distributed problem- 
solving activities cannot be accomplished within 
the scope of an individual logical transaction be- 
tween two remote applications. Consider, for ex- 
ample, a distributed decision support system com- 
posed of two or more independent tools, such as a 
planning system and a scheduling engine. Suppose 
that the planning system incorporates the master 
database for all decision support information, in- 
cluding all operational plans and schedules for the 
target domain. Assume also that the models used 
to represent data and knowledge are incompatible 
across the two tools, which is common for indepen- 
dent systems specialized to solve different problems. 

In this context, an elaborate set of information 
and control exchanges has to take place to perform 
scheduling. Data must be extracted from the plan- 
ning system’s database, transferred to the sched- 
uler, translated into a format that is compatible 
with the scheduler, and then loaded. At this point, 
the primary scheduling activity itself can proceed. 
Once scheduling has been completed, a similar set 
of support transactions must be accomplished in 
reverse order. The completed schedule must be 
translated into a format acceptable to the plan- 
ner, transferred back to the planner’s host platform, 
and incorporated into the master decision support 
database. 

Clearly, such sequences need to be automated, 
both for end-users and for autonomous manage- 
ment systems. It should be possible to invoke 
scheduling or comparable functions through sim- 
ple, high-level commands. Such commands should 
specify only the few data items that are required 
to characterize particular instances of the desired 
task type (e.g., a mission identifier, options to over- 
ride default control parameters for the scheduling 
engine). This amounts to a requirement to auto- 
mate composite activities, or processes , composed 
of multiple discrete interactions between indepen- 


dent distributed applications. The HDC-Manager 
Agent currently lacks the requisite capabilities ei- 
ther to define such distributed problem-solving pro- 
cesses or to coordinate their execution. We consid- 
ered several design approaches to extend SOCIAL 
to provide the desired functionality. 

One alternative would be to configure a dis- 
tributed system so that one message would initiate 
the desired activity sequence by triggering the first 
application Gateway to perform its assigned task, 
pass the results onto a second Gateway to perform 
the second required task, and so forth. In other 
words, a single message to the first server Agent 
would automatically initiate the desired chain of in- 
teractions. SOCIAL’s communication layer main- 
tains a “travel log” for each message as it is passed 
through Agents. Once the “terminal” Agent com- 
pletes its activities, results are automatically re- 
turned and post-processed through all preceding 
Agents that appear in the message’s log. 

Unfortunately, the logic for parsing and for- 
warding messages within individual application 
Gateway Agents can become quite involved for 
complex processes. Moreover, a given application 
Agent may have to perform a given function within 
multiple process sequences, with different successor 
Agents and post-processing activities for each dis- 
tinct chain. Maintainability and extensibility are 
compromised in that each time a new process is de- 
fined, the control logic for Gateway Agents in that 
process chain must be modified. Consequently, for 
mission critical applications, the entire suite of be- 
haviors for each affected Agent has to be verified 
again. Finally, SOCIAL’s communication model 
only supports acyclic message forwarding, preclud- 
ing processes involving “back-and-forth” exchanges 
or iterative looping. 

A second alternative would be to extend the 
HDC-Manager directly to support the specification 
and execution of distributed sequential processes. 
On this strategy, special “macro” tasks would be 
definable in the HDC-Manager’s directory knowl- 
edge base, corresponding to composite processes. 
A message requesting execution of such a com- 
posite task would activate extended control logic. 
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This logic would decompose macro tasks into con- 
stituent service requests and post individual steps 
to the task agenda, in suitable order, for the II DC- 
Manager to process and route. 

This approach resolves the objections raised 
against the previous design strategy. First, mes- 
sages are only passed between the extended HDC- 
Manager and individual application Agents, elimi- 
nating the hardwiring of interaction sequences di- 
rectly into the control logic for individual Gate- 
ways. Second, the new macro processes are modu- 
lar, maintainable, and readily extensible. In partic- 
ular, processes are modeled independent from and 
external to individual application Agents. System 
testing is simplified because new processes can now 
be defined without affecting previously verified pro- 
cesses and Agent behaviors. Finally, the extended 
H DC- Man ager mediates all interactions between 
application Gateways as separate message trans- 
actions. SOCIAL’s acyclic message-passing model 
can accommodate cyclic behaviors that are broken 
up in this manner. 

The main objections to extending the HDC- 
Manager are performance and complexity. This 
Agent’s primary design role is to eliminate direct 
connections between application Agents by medi- 
ating interactions. The proposed functional exten- 
sions decompose macro tasks and manage queueing 
of process subtasks. These capabilities for man- 
aging distributed processes impose computational 
overheads that reduce the responsiveness of this 
core routing capability. Moreover, these design ex- 
tensions also complicate the original control logic 
of the II DC- Man ager significantly. 

We adopted a third approach, which distributes 
the functionality of the extended HDG-Manager to 
overcome these design problems. Specifically, cen- 
tralized process definition and management func- 
tions arc retained, but decoupled from the HDC- 
Manager and assigned to a new subclass of Manager 
Agents called Process-Planners. The distributed 
control model realized in the Process- Planner is 
then configured to drive the H DC-Manager through 
the individual process steps comprising composite 
activity sequences. It does this by posting succes- 


sive service requests to the II DC-Manager’s agenda 
for distributed routing. This basic architectural 
configuration is depicted in Figure 3. 
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Figure 3: SOCIAL Process Control Architecture 

This distributed design is attractive because it 
enables the II DC-Manager to function identically 
for two distinct distributed computing models - 
transaction-based and process- based The Process- 
Planner manages process decomposition and ac- 
tivity sequencing. It transmits individual process 
steps as individual service requests to the II DC- 
Manager, replicating the type of inputs that would 
be expected from ordinary application Gateway 
Agents. Consequently, the II DC- Manager need not 
distinguish between discrete and composite service 
requests within its agenda. In fact, process steps 
and service requests representing discrete Gate- 
way transactions can be interleaved on the II DC- 
Manager’s agenda, enabling both kinds of inter- 
actions to be coordinated concurrently. In addi- 
tion, partitioning distributed control logic across 
two Manager Agents fosters modularity, maintain- 
ability, and extensibility. 

The message traffic between the Process Plan- 
ner and HDC-M anager entails some performance 
overhead. However, the t wo Agents ( oiiimuiiicnte 
asynchronously and can operate concurrently on 
dedicated processors, compensating at least, in part 
for message-passing overhead . Overall performance 
depends strongly on the part icular distributed sys- 
tem and its ratio of communication and coordina- 
tion to local application problem-solving loads. 
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Implementing the Process-Planner Agent 

The Process-Planner Agent was implemented as a 
subclass of SOCIAL Gateways. Consequently, it 
inherits the standard Gateway peer-to-peer con- 
trol model and API methods. These methods were 
specialized to interface with the core process plan- 
ning application. The data injection API method 
parses two SOCIAL neutral exchange types. Char- 
acter strings are interpreted as pathnames for files 
containing process scripts, which the planning sys- 
tem loads into memory. Lists are treated as com- 
mands and command arguments, which are exe- 
cuted through the application’s control interface 
(e.g., initialize, reset). Extensions to handle other 
data types amount to straightforward program 
Case statement clauses. The API method for ex- 
tracting information was not required, because the 
process planning system functions solely in a client 
role. 

The process planning application examines a 
process script to determine the next step to per- 
form. Currently, a script consists of an ordered 
list of entries that correspond to services identi- 
fied in the directory knowledge base of the asso- 
ciated HDC-Manager Agent. The :compute-next- 
step command retrieves the first script item that 
has not been instantiated. An item has been in- 
stantiated if it has been annotated with execution 
results returned from the HDC-Manager. 

The planning program also computes prede- 
cessors and successors to current steps in process 
scripts. The HDC-Manager supports a generic file 
transfer service based on SOCIAL utility agents 
that send and receive files across network nodes. 
This service is context-sensitive in that it presup- 
poses source and target file pathnames and host 
names. The HDC-Manager can determine these 
items given the previous and succeeding script steps 
to the current file transfer task. 

The Process- Planner Agent starts up the em- 
bedded planning program in response to a mes- 
sage that specifies initialize and reset commands, 
together with the name of a script file to load. A 
second message initiates the following control cycle: 


1. the Agent determines the next process step 
from the process planner program and dis- 
patches a suitable service request message to 
the HDC-Manager; 

2. the HDC-Manager dequeues the request from 
its agenda, finds the server application Agent 
(e.g., a Gateway for a scheduling engine, a 
Send-File utility), and dispatches an appropri- 
ate task message to that Agent; 

3. the target application Agent performs the as- 
signed task and posts its response to the HDC- 
Manager’s bulletin-board. Typically, the tar- 
get Agent is a Gateway, which interacts with 
its embedded application by injecting data or 
commands and collecting query or problem- 
solving results; 

4. the HDC-Manager automatically routes the 
posted task results back to the Process-Planner 
Agent; 

5. the planning program updates the instanti- 
ated script with service request results and 
computes the next step from the script. The 
Process-Planner dispatches this new process 
step back to the HDC-Manager for routing. 

The Process-Planner then reiterates this exe- 
cution cycle. The Agent terminates looping when 
notified by its embedded process planning program 
that the script has been completely instantiated. 

The Process-Planner plays the role of a Man- 
ager Agent in that it performs distributed control 
functions rather than integrating domain-specific 
applications. However, it was designed and im- 
plemented as a subclass of Gateway Agents. So- 
phisticated process planning tools are beginning to 
appear commercially in CAE, CAM, and CASE do- 
mains. These tools are used to specify task decom- 
positions and automate control of work flows for 
machining complex parts, other manufacturing pro- 
cesses or managing large projects. The Gateway’s 
uniform, high-level interface architecture preserves 
design flexibility to replace the SOCIAL process 
planning program with a more powerful dedicated 
engine. 
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Distributed Decision Support Prototype 

A prototype was developed to validate this de- 
sign model for coordinating processes in SOCIAL. 
This prototype simulates a distributed decision sup- 
port system for ground operations activities for the 
Space Shuttle fleet at the NASA Kennedy Space 
Center. Specifically, a Process-Planner Agent was 
implemented and coupled to an HDC-Manager. 
These two Agents automatically coordinate the 
complex sequence of distributed activities required 
to schedule Shuttle missions. 

Two (simulated) decision support applications 
were integrated using SOCIAL Gateway Agents 
(cf. Figure 4). One Agent represents a commer- 
cial planning system called Artemis, which NASA 
has modified with a frontend interface customized 
for planning ground support activities for Shut- 
tle missions. The second Agent represents an in- 
telligent, constraint-based scheduling engine called 
Gerry (Zweben, 1990), which is being developed by 
the NASA Ames Research Center. Artemis is based 
on a proprietary fourth generation language and re- 
sides on an IBM mainframe host. Gerry, written in 
Common Lisp and CLOS, runs on Unix worksta- 
tions. 

The Artemis Gateway Agent is configured to 
simulate three tasks: (a) downloading data files 

for a particular mission from the Artemis master 
planning database; (b) uploading data files rep- 
resenting a completed mission processing schedule 
back into Artemis; and (c) running an analysis pro- 
gram to detect and report resource conflicts be- 
tween the new schedule and existing schedules for 
other Shuttle missions. The Gerry Gateway also 
simulates three tasks: (a) translating and loading 
mission plan files into the scheduler; (b) computing 
the mission schedule; and (c) extracting and trans- 
lating the completed schedule back into Artemis- 
compatible file format. 

The Gerry scheduler requires four types of plan 
information: a network of tasks to be performed 
to prepare the Shuttle vehicle and its associated 
payload(s) for launch; a specification of available 
resources (e.g., labor schedules, equipment such as 


cranes, and other materials); a set of constraints on 
tasks and resources; and a data dictionary that de- 
scribes the information fields in the preceding three 
datasets. Artemis generates these datasets as four 
ASCII files in a standardized record format. Gerry 
requires data to be input from ASCII files in a cus- 
tom object-oriented format. 


Gerry Gateway ARTEMIS Gateway 




API Method#: 
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Figure 4: Prototype Decision Support Gateways 


SOCIAL’s data management subsystem was 
used to define custom neutral exchange data struc- 
tures. Translators were written to map between 
Artemis and SOCIAL data models and between 
Gerry and SOCIAL data models (cf. Figure 5). 
The translators were hooked into the application 
Gateway Agent interface API methods to perform 
appropriate conversions of data file formats. Data 
files are translated into neutral exchange format 
structures in memory, and then written to new files 
in the target converted format. 
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Figure 5: Disparate Decision Support Data Models 

A subclass of HDC-Manager Agent, called the 
DSS-MGR, was created to coordinate interactions 
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between the two decision support applications (cf. 
Figure 6). Three steps were required to specialize 
the DSS-MGR Agent for this purpose. First, con- 
ditions were defined for prioritizing agenda service 
requests. The DSS-MGR sorts requests with re- 
spect to an ordinal list of service types. Requests of 
the same type are ordered by increasing values of a 
numeric priority attribute. Second, the DSS-MGR 
directory knowledge base was constructed. The di- 
rectory identifies all services available from all ap- 
plication Gateways subordinate to the DSS-MGR, 
plus the generic file transfer capability. Both DSS- 
MGR attributes are defined using the high-level 
declarative API specific to HDC-Manager Agents. 
Third, dispatching functions were written for each 
directory service entry. These functions manipulate 
data arguments contained in service request mes- 
sages into a task message that the HDC-Manager 
routes to the relevant application Gateway server. 


DSS-Mgr Agent 



Figure 6: Decision Support HDC-Manager Agent 

Next, a script was written for the Process- 
Planner Agent, defining the distributed process for 
scheduling Shuttle missions. This sequence consists 
of the following steps: 

(retrieve-Artemis-data) 

(transf er-data-f iles) 

(load-Gerry-data) 

(schedule-mission) 

(retrieve-Gerry-data) 


(transf er-data-f iles) 

(load-Artemis-data) 

(Artemis-analyze-and-report) 

File format conversions currently take place 
within the load-Gerry-data and retrieve-Gerry-data 
tasks. Once the various Agents are loaded and ini- 
tialized, the mission scheduling sequence is initiated 
through a simple message to the Process-Planner 
Agent to compute the next step for a particular mis- 
sion, such as STS-40. The Process-Planner Agent 
then executes the control loop described in the pre- 
vious section against the mission scheduling script. 

All demonstration Agents and simulated appli- 
cations were written in Common Lisp. The demon- 
stration system can be run on a single platform or 
combination of platforms that currently run S0- 
CIAL/Lisp, including Apple Macintosh I Is , Lisp 
Machines, and Unix workstations. The Agent Li- 
brary is currently being converted to C, to run on 
SOCIAL/C workstation hosts. A planned port of 
SOCIAL/C to the IBM/VM environment will es- 
tablish direct interprocess interfaces across main- 
frames and workstations. NASA’s distributed de- 
cision support system can then be implemented on 
the intended target platforms. 

FUTURE DIRECTIONS 

The Process-Planner Agent is being redesigned 
with extended functionality. The original planning 
program only supports simple sequential scripts. 
These scripts cannot specify data-driven processes, 
in which successive steps are determined dynam- 
ically at runtime, contingent on the results of 
preceding process steps. Moreover, the initial 
Process-Planner drives the HDC-Manager to ex- 
ecute script steps individually, in a strictly syn- 
chronous, “execute and wait” sequence. Ideally, 
the Process-Planner should be able to request the 
HDC-Manager to route all script activities that are 
mutually independent within a single control cycle. 
To overcome these limitations, a more expressive 
scripting language will be developed for specifying 
processes that incorporate conditional branching, 
iteration, and concurrent tasking. The Process- 


54 



Planner’s control logic will be extended accordingly. 

A capability for executing multiple scripts simulta- 
neously will also be added. 

A second set of enhancements will provide more 
formal development tools for creating and manag- 
ing script libraries, replacing the ad hoc techniques 
used in the prototype Process-Planner. A menu- 
based editor will be developed to access and manip- 
ulate process scripts. Also, scripts will be stored in 
a central database of process plans rather than in 
an arbitrary collection of independent files. 

Other development efforts will extend SO- 
CIAL’S library of Manager Agents. The current 
HDC-Manager is adequate for distributed systems 
in which a single application Agent represents the 
unique source for a given resource or service. How- 
ever, additional control requirements arise for ap- 
plication networks in which multiple application 
Agents can provide data, knowledge, or problem- 
solving skills redundantly. For example, identical 
copies of a program may be available on several 
nodes. In addition, some applications may have 
overlapping functionality for planning, scheduling, 
or other tasks. A dedicated “Server-Group” Agent, 
inspired by the ISIS model for group-based tasking 
(Birman, 1990), is being designed to address dis- 
tributed control issues for functionally redundant 
application networks. Like the Process- Planner, 
this Agent will be configured to offload new con- 
trol capabilities and work cooperatively with the 
HDC-Manager. Specifically, the Server-Group will 
monitor availability of server Agents, determine the 
best server for a task, and enable redundancy-based 
approaches to fault tolerance. 

RELATED WORK 

Alternative frameworks for developing heteroge- 
neous, distributed intelligent systems include ABE 
(Hayes-Roth, 1988), MACE (Gasser, 1987), Agora 
(Bisiani, 1987), and Cronus (Schantz, 1986). 
MACE incorporates dedicated manager agents for 
centralized routing of messages among applica- 
tion agents. However, MACE managers lack the 
other capabilities of SOCIAL HDC-Managers, such 


as shared memory, transparent returning of mes- 
sage responses, and extensibility for multi-level 
control hierarchies. Like SOCIAL, ABE, Agora, 
and Cronus all provide virtual environments to 
shield users from platform dependencies and net- 
working mechanics. However, they do not im- 
plement generic distributed services in uniform, 
object-oriented layers that are accessible to devel- 
opers for customizing. Agora relies on communi- 
cation through shared-memory, reflecting its ori- 
entation towards parallel multi-processing architec- 
tures. The other tools use message-passing models 
comparable to SOCIAL. ABE and Agora provide 
predefined control frameworks such as data flow 
and blackboard models. Unlike SOCIAL Manager 
Agents, these models explicitly couple individual 
applications directly to one another. Moreover, het- 
erogeneous SOCIAL Manager Agents can be con- 
figured to work together cooperatively. It is unclear 
whether the other tools support such combinations 
within a given distributed systems. 

The literature on distributed artificial intelli- 
gence (DAI) contains many interesting architec- 
tures for cooperative problem-solving, including 
blackboard systems, contract nets, and collections 
of autonomous agents (Bond and Gasser, 1988) In 
this context, cooperation refers to loosely-coupled 
networks of intelligent Agents working to solve a 
single complex problem through collective action. 
Most such DAI architectures rely on purely local- 
ized control models duplicated across homogeneous, 
autonomous agents. These designs can be repli- 
cated within the generic communication and con- 
trol model provided by SOCIAL Gateway Agents. 

More recent DAI research focuses on theories 
of cooperation for open-ended systems composed of 
arbitrarily heterogeneous applications (Gasser and 
Iluhns, 1989). The critical problem here is to de- 
sign dynamic interaction protocols for communi- 
cating self-descriptive goals, plans, and intentions 
among agents with radically different, knowledge 
and perspectives. SOCIAL Managers currently ad- 
dress more modest closed-world domains, in which 
the resources available in an agent network are spec- 
ified ft priori and statically. A synthesis of Man- 
ager control models with dynamic interaction pro- 
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tocols could contribute to a powerful theory of co- 
operation for open networks of autonomous agents: 
agents and their resources could be registered dy- 
namically in the context of a partially centralized 
control architecture that mediates agent interac- 
tions. 

CONCLUSIONS 

SOCIAL applies a highly modular, non-\ntru$%vt 
object-oriented approach to simplify the design 
and implementation of complex distributed sys- 
tems (cf. Figure 7). High-level Agent APIs parti- 
tion generic distributed computing and application- 
specific functionality. Gateway Agents provide a 
uniform methodology and design architecture for 
integrating heterogeneous applications, both intel- 
ligent and conventional. Manager Agents provide 
high-level distributed control building blocks for ty- 
ing application Gateways together. Coordinating 
via Managers eliminates direct connections between 
individual application Agents that are difficult to 
maintain and extend. 



Figure 7: SOCIAL Library Building Blocks 


The prototype distributed decision support sys- 
tem described earlier illustrates capabilities for: 

• integrating independent planning and schedul- 
ing engines across a computer network; 

• automating distributed interprocess commu- 
nication, namely 'Tine-grained” exchanges of 
data and control between remote executing ap- 
plications; 


• automating conventional “coarse-grained” in- 
teractions such as file transfers across dis- 
tributed application platforms; 

• automating the coordination of complex se- 
quences of fine- and coarse-grained interactions 
between distributed applications through high- 
level, declarative scripts. 

The coordination capabilities provided by SO- 
CIAL Manager Agents have broad applicability for 
distributed intelligent systems in space-related do- 
mains. For example, process scripts could be used 
to coordinate routine shop floor activities. Task 
control and work-in-progress status data could be 
routed automatically among Shuttle and payload 
processing facilities scattered across the Kennedy 
Space Center complex. Similarly, shop floor statis- 
tics could be collected, summarized, and transmit- 
ted to higher-level decision support systems. Mis- 
sion schedules could be monitored and managed 
more effectively. This feedback could also be used 
to tune the processing estimates that drive long- 
term planning of Shuttle missions. 

In addition, process scripts could be used to au- 
tomate standardized launch processing and mission 
control disciplines, enhancing productivity, safety, 
and quality assurance. Beyond decision and oper- 
ations support applications, process scripts can be 
used to automate routine flows of information in 
office automation and concurrent engineering con- 
texts. Finally, process scripts can be applied in 
space science domains for automating sequences of 
data retrieval, analysis, and graphic visualization 
activities. End-users could develop, maintain, and 
extend their own application-specific scripts. 
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